[セッションレポート]How Dropbox Scales Massive Workloads Using Amazon SQS #reinvent

re:InventにてDropboxがSQSをどのように大規模に使っているのか、というセッションを聴講してきました。以下に内容を箇条書きで残しておきます。

内容まとめ

• Dropboxにとって「同期」というものが最もコアな競争力
  • 共有
  • コラボレーション
• 「同期」を実現するための課題: いかにして巨大なワークロードを、アップロードされたその瞬間に実施するか。
• アップロードされた後、ファイルの種類によって様々な処理を実施し、メタデータを取得する必要がある。
  • 画像ファイル: EXIFの取得、サムネイル取得
  • 動画ファイル: エンコード
  • などなど
• 同期時の処理は以下の制約を満たす必要がある
  • 低レイテンシ
  • 高スループット
  • 様々な処理への柔軟な対応
• Dropboxではこれまでに様々なアーキテクチャを試してきた
• 最初に、オンプレのDropbox環境でファイル処理しS3へと保存する構成
  • 問題点: オンプレとAWS間の通信コストが高過ぎる
• EC2のアプリケーションサーバで処理を実施、コンテンツをS3にアップロードしメタデータをオンプレ環境に送信するアーキテクチャに変更。
  • ネットワークの問題は解消できたが、負荷分散に難がある。新しいロジックを追加するための柔軟性が低い。

    

• 最終的に、内部的に「Livefill」と呼ばれるアーキテクチャを作成
• SQSをInput、Intermediate、Outputとして利用する構成
• 何万というファイルを秒間で処理することができるようになった
• 設定はYAMLで記載する。柔軟な変更・調整が可能になった。
• EC2はSQSのQueue lengthに応じて台数を柔軟に変更するようにしている
• SQSを利用することでキュー自体の管理は不要。この巨大システムをたった2名のエンジニアでメンテナンスしている。
• SQSにPublishする際にはQueue Lengthに気を使うようにする。あまりにも貯まりすぎている場合にはPublish側で制御する必要がある。SQSは時系列のQueueではないので。
• 失敗したJobは再度キューに入れなおすような処理を別途作っている。
• 現在、平常時で20,000QPS、バースト時で300,000 QPSのワークロード。
• 秒間450,000のジョブが実行される。
• 今後はこのシステムをマルチリージョン化、リージョン間フェイルオーバーなど、さらに柔軟に、AWSの特性を活かしきったシステム構成にしていきたい。

まとめ

DropboxではSQSを利用することで、高速かつ大量の処理を実施することを可能にしています。このアーキテクチャとSQS利用法は非常に有用だと感じました。